Skip to content

Conversation

@HolonProduction
Copy link
Member

Removes 24 bytes from Object since the script was stored as Variant. Instead obtains the script from the ScriptInstance.

As far as I can see Object::get_script is not used in any obvious hot paths, so the additional overhead should not matter that much.

In addition to making object smaller, this is also makes inconsistent states impossible.

Copy link
Member

@Ivorforce Ivorforce left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks! This makes sense to me. There's no need for script to be stored twice, especially since the Variant based storage can be less efficient and more error prone than the reference based one.
Would be nice to get another voice from one more GDScript / C# maintainer, but I also don't see huge risks in this. The property has existed since the first commit. It's likely simply no longer needed.

@Ivorforce Ivorforce requested a review from a team October 9, 2025 09:10
@dalexeev
Copy link
Member

dalexeev commented Oct 9, 2025

We should especially carefully check PlaceHolderScriptInstance and tool mode. Also, I remember there was a bug where the script was assigned but the script instance wasn't, but I couldn't find the issue.

@HolonProduction
Copy link
Member Author

I did look at PlaceHolderScriptInstance when making the PR. To me it looks like they are always created with a valid script. Not that familiar with tool mode. What might be a pitfall? Doesn't tool mode create normal script instances?

Copy link
Contributor

@dsnopek dsnopek left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks!

This looks good to me. I'm glad this is also removing set_script_and_instance() - when working on PR #102373 it was also noted that this method isn't really needed.

There is one potential risk here: if there are any GDExtensions providing scripting languages that depend on the Ref<Script> getting cached on the Godot side, and won't expect get_script() to get called so often. However, I think at worst this would be a performance issue, and not one that breaks compatibility? So, I think it should be fine

@HolonProduction
Copy link
Member Author

It could be compat breaking for an implementation that tries to obtain the script from the Object it's attached to. But that sounds pretty hypothetical.

Still it technically breaks compat in a way that should at least be documented.

Copy link
Member

@dalexeev dalexeev left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks good to me too, great catch! Even if we encounter some regression, we can always fix it or revert the change.

Copy link
Member

@raulsntos raulsntos left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The C# changes look good to me.

@HolonProduction
Copy link
Member Author

Regarding tool mode, I did try this with my kanban board addon and on a cursory look everything seems to work alright.

@Repiteo Repiteo modified the milestones: 4.x, 4.6 Oct 10, 2025
@Repiteo Repiteo merged commit e33f89f into godotengine:master Oct 10, 2025
20 checks passed
@Repiteo
Copy link
Contributor

Repiteo commented Oct 10, 2025

Thanks!

@HolonProduction HolonProduction deleted the rm-script branch October 10, 2025 19:18
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

7 participants